home *** CD-ROM | disk | FTP | other *** search
/ Turnbull China Bikeride / Turnbull China Bikeride - Disc 2.iso / BARNET / ARMLINUX / MAIL / 9804 / 000077_linux@arm.uk.linux.org _Sun Apr 19 11:50:25 1998.msg < prev    next >
Internet Message Format  |  1998-05-13  |  6KB

  1. Return-Path: <linux@arm.uk.linux.org>
  2. Received: from snowcrash.cymru.net (snowcrash.cymru.net [163.164.160.3])
  3.     by odie.barnet.ac.uk (8.8.6/8.8.6) with ESMTP id LAA07730
  4.     for <willy@odie.barnet.ac.uk>; Sun, 19 Apr 1998 11:50:24 +0100
  5. Received: from caramon.armlinux.org (dialup1.cymru.net [163.164.160.65]) by snowcrash.cymru.net (8.8.7/8.7.1) with ESMTP id LAA04717; Sun, 19 Apr 1998 11:51:34 +0100
  6. Received: from raistlin.armlinux.org (raistlin [192.168.0.3]) by caramon.armlinux.org (8.7.4/8.7.3) with ESMTP id MAA24752; Sun, 19 Apr 1998 12:06:39 +0100
  7. From: Russell King - ARM Linux Admin <linux@arm.uk.linux.org>
  8. Received: (from linux@localhost) by raistlin.armlinux.org (8.7.4/8.7.3) id LAA01114; Sun, 19 Apr 1998 11:46:42 +0100
  9. Message-Id: <199804191046.LAA01114@raistlin.armlinux.org>
  10. Subject: Re: fd0* device for ADFS shape discs under i386 Linux
  11. To: root@mad.scientist.com (James Craig)
  12. Date: Sun, 19 Apr 1998 11:46:42 +0100 (BST)
  13. Cc: willy@odie.barnet.ac.uk, ajb85@cam.ac.uk, linux-arm@vger.rutgers.edu
  14. In-Reply-To: <Pine.LNX.3.96.980418082122.418C-100000@darkside.hacknet.uk> from "James Craig" at Apr 18, 98 08:24:41 am
  15. X-Mailer: ELM [version 2.4 PL24]
  16. MIME-Version: 1.0
  17. Content-Type: text/plain; charset=US-ASCII
  18. Content-Transfer-Encoding: 7bit
  19. Status: RO
  20.  
  21. James Craig writes:
  22. > On Fri, 17 Apr 1998, Matthew Wilcox wrote:
  23. > >Andrew Bower
  24. > >> Out of interest, is anyone working on write support for ADFS?
  25. > >
  26. > >I've looked at the current code.  It would be hard to add extendable
  27. > >files to it, though in principle, files which are newly created and stay
  28. > >the same length should be able to work quite easily.
  29. > >
  30. > >The trouble is that ADFS (or more truthfully filecore) does not have
  31. > >the concept of the inode.  Inodes are what Unix filesystems are built of.
  32. > >They have the following properties:
  33. > >
  34. > >Each file has an inode
  35. > >The inode remains the same during the life of the file
  36. > >Inodes do not map to more than one file.
  37. > >The inode contains all of the metadata for the file except its name.
  38. >
  39. > umm. ADFS doesn't have inodes in the same way UNIX does, but couldn't you
  40. > get away with the file's ID that appears in the free space map? (He said,
  41. > trying to talk knowledgably, despite the fact that it's 5 years since he
  42. > last wrote an ADFS-E-format-filing-system-reader).
  43.  
  44. I did toy with that idea, after all,  it is quite unique.  However, you stumble
  45. on a small problem:
  46.  
  47. Under Unix, a filename translates to an inode.  An inode then gives you the
  48. file data, and attributes.
  49.  
  50. Under Filecore, a filename translates to a fragment ID + attributes.  A
  51. fragment ID translates to file data.
  52.  
  53. Hence, if you do use the fragment ID for the inode number, then yes, you can
  54. access the file's data, but you can't get the inodes attributes, since you
  55. don't know where these are stored on the disk.
  56.  
  57. I did at one point use a combination of the fragment ID for the parent directory
  58. and the fragment ID of the file, but 32-bits isn't enough to store this and
  59. the sector offset required.
  60.  
  61. This method still isn't acceptable for a writable ADFS - if the file is moved from
  62. the directory to another, then it's parent ID changes...
  63.  
  64. > The IDs still only map to one file, aren't likely to change over it's
  65. > lifetime, and the only problem you have is that the length info is kept in
  66. > the directory info.
  67.  
  68. Exactly.
  69.  
  70. > >I cannot think of a good way of faking inodes for ADFS filesystems *except*
  71. > >the following rather horrible idea:
  72. > >
  73. > >Create a structure in memory for each ADFS filesystem mounted.  This can
  74. > >be done lazily.  Assign each file an inode based on some scheme which will
  75. > >allow for easy mapping between it and the name of the ADFS file.  Perhaps
  76. > >hash buckets.  Note that it's okay to reuse inodes once a file has been
  77. > >deleted.
  78. >
  79. > Ur, YUK!! That would be horrible. I mean, mapping names to inodes is gonna
  80. > break as soon as you move a mile about the FS somewhere.
  81.  
  82. I think that this is horrible, but may be the only way.
  83.  
  84. > >Someone should look at other filing systems to see how they cope with
  85. > >filesystems that don't provide nice inodes.  When Dickon Hood & I were
  86. > >experimenting with NFS servers under RISC OS, we had a structure that
  87. > >worked well; it was a tree, and the inode we returned was the address
  88. > >within that list.  You've got me intrigued now, I might just do it.
  89. >
  90. > Good man, writable ADFS would be nice. :)
  91. >
  92. > >The way Russell has done it is faster than this method for read-only
  93. > >but will not extend to writable files.
  94. >
  95. > I haven't looked at it yet, but what's he done that stops you writing
  96. > files the same way?
  97.  
  98. The problem is that the inode number depends on the position of the directory
  99. on the disk and the offset into the directory.  If you add a file, then
  100. as far as the Linux VFS is concerned, all the inodes on that disk have changed,
  101. and all inodes must be refreshed.  NFS will go mad (since it depends on inodes
  102. staying the same), as will things like `pwd'.
  103.  
  104. Linux needs to be able to map an inode number directly to a file on ADFS -
  105. this is the first problem that someone's going to have to crack when allowing
  106. ADFS to be writable.
  107.    _____
  108.   |_____| ------------------------------------------------- ---+---+-
  109.   |   |        Russell King       linux@arm.uk.linux.org      --- ---
  110.   | | | |  http://www.arm.uk.linux.org/~rmk/armlinux.html    /  /  |
  111.   | +-+-+                                                     --- -+-
  112.   /   |               THE developer of ARM Linux              |+| /|\
  113.  /  | | |                                                     ---  |
  114.     +-+-+ -------------------------------------------------  /\\\  |